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(54) Title: SYSTEM AND METHOD FOR DATA ACCESS 
(57) Abstract 

A client-server system utilizing a stateless protocol to 
access server data over a network (55). Such a system may 
implement online transaction processing, where a client (60) 
utilizes specialized computer software to provide entry forms 
to indicate information to be retrieved from an application 
server (50). A unique identifier is generated to identify a 
particular client, and is embedded into communications between 
the client (60) and the application server (50). the presence of 
the identifier causing the application server (50) to maintain an 
active network connection (55) to the client, as well as allowing 
the application server to maintain server-side state information, 
such as information to be distributed to the client computer, 
the client identifier, and other desired information regarding the 
client's activities. Maintaining an active connection, as opposed 
to continually dropping and reinitiating contact, reduces network 
overhead. A database server (40) may operate in conjunction 
with the application server (50) through communications over 
a second network connection (45) for storing the server-side 
nformation. The application server (50) may be implemented 
using Web server technology. If the HTTP Hypertext Transport 
Protocol is used on a network (55) to communicate with the 
client (60), the n the Client (60) may use any operating system 
supporting the HTTP protocol. 
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SYSTEM AND METHOD FOR DATA ACCESS 
DESCRIPTION 

5 

TECHNICAL FIELD 
This invention relates to computer systems, and more particularly to client-server 
computer systems that provide access to on-line data. 

1 0 BACKGROUND OF THE INVENTION 

A common use of client-server computer systems is the retrieval of information by the 
client system of data stored on a server system over a network connection. The network 
involved in such a retrieval may be the public Internet or a private Intranet. An Intranet is a 
private network, generally augmenting or replacing a Local Area Network (LAN) within an 

15 office, yet based upon the widely available Internet technology. One part of the Internet 

technology of current interest is the HTTP Hypertext Transaction Protocol, the protocol that 
carries the network communications between many existing client and server systems. As 
with most networking protocols, HTTP is a high-level set of networking functions that rides 
on top of lower-level basic network protocols. A good example of a superset protocol is the 

20 well-known TCP/IP high-level protocol, which is built on top of the low-level IP protocol. IP 
is essentially the assembly-language of networking protocols. It offers very basic low-level 
functions for forming a network connection between two locations on the network (such as 
between a client and a server), but IP offers very little error handling recovery. In contrast, 
TCP/IP builds off of IP to provide features to guarantee error-free transmissions over the 

25 network. In this same fashion, the HTTP protocol builds on present day networking protocols 
to allow efficient client-server connections over a network where it is expected that a large 
volume of data (principally due to graphics information) will be transferred between the two. 

In its most common form of use, HTTP is a stateless protocol. The "state" of a client- 
server transaction refers to what the client is doing/requesting now, in relation to the past 
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history of requests to the server. A stateless protocol means that the communications are one- 
way requests, and that the requests are not being tracked. Thus, in the client-server context, 
every time a client wanted information, the client would have to make fully encapsulated 
requests to a server. The server would receive the request, process it and send the client the 
result, and then immediately drop the connection between the server and client. After the drop 
there is no persisting record at the server of information related to the communication channel 
that was just closed, and no information related to the client system or to the specific user of 
the client system. Therefore, if the client needed the "address" information again from a 
previous request, it could not simply transmit a "send me that address-data again" request as 
the reference to "address-data" requires the server to have maintained a state history for the 
client in order for the server to know what was sent before. 

Consequently, follow-on communications between the client and server that are 
logically connected, for example follow-on communications regarding the same previous user 
or the same previous topic, require that a new communication channel be established for the 
follow-on communications without reference to or use of prior information. This process 
requires a repeat expenditure of system overhead by both the client and the server systems to 
set up a new channel for each HTTP communication, as well as expenditure of other 
resources to re-transmit information from the client to the server that may be needed to access 
the information being sought. In effect, the client is required to transmit state information to 
the server if the client wishes to perform an ongoing dialog with the server. 

For many practical applications, the stateless connection is adequate. For example, 
when a human user is utilizing a client system to access a data source located remotely using 
the Internet, related follow-on requests are relatively infrequent, so dropping and re- 
establishing a new communication channel is efficient, and client system or user information 
is often not required for data access. In other more data intensive applications, however, 
client information and/or communication channel information is frequently important to 
retain. Such applications include on-line transaction processing system (OLTP). which 
includes both reading and changing data, or on-line access processing (OLAP), which 
includes only reading data. 
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In such data intensive systems, requiring the client to transfer state information along 
with the data requests can make the client-server relationship extremely inefficient. Having 
the server retain client state information over a stateless connection is a way to avoid the 
inefficiency as well as to increase total system capacity; these two benefits are features of the 
present invention. 

For present purposes, the invention will be described here in terms of an OLTP, 
however it will be understood that the present invention has broader application than the 
OLTP system described. The invention may find utility in any communications system 
requiring multiple interactions or transactions within a user session, and which provides client 
context within the server for follow-on interactions. 

An on-line transaction processing system (OLTP) typically provides a computer 
system comprising a client-server arrangement having three tiers, although a two tier system 
will also be described below for completeness. A plurality of client systems at the first tier 
level having keyboards and display monitors provide input and output directly to human users 
who have a need to remotely access a database of information records. Network connections 
connect the client systems to a second tier comprising application servers that provide the 
application software such as an inventory control system or an airline reservation system that 
deals with user requests, performing data collection and validation and supplying user 
responses and other application services. Network connections connect the application servers 
to a third tier comprising, typically, a single or small number of database servers that contain 
the basic information records, e.g., inventory or airline seats, that are queried and updated as 
the human users interact with the data through the application system. Networks in an OLTP 
may be local area networks or wide area networks as the physical distances between the client 
and the server systems requires. 

In the past, most OLTP systems have used an operating system sold under the UNIX 
brand name by a number of commercial suppliers, in the computer systems at all three levels, 
client system, application server and database server, in order to control software operation 
and network communications with the other tiers. More recently, it has been desired to use an 
operating system sold under the Windows brand name as Windows NT Server available from 
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Microsoft Corpora.™ of Redmond, Washington a, >he applica.ion server ,ier. and, in some 
cases, one or more different versions of Windows at all three tiers. 

Using Windows NT Server as the application server permits the application server to 
be advantageously implement using a combination of current commercially avatlable 
hardware and software products, the combination generally referred ,0 as a Web serve, wtth 
most development implemented under .he Windows operating system. A Web server 
comprises a hardware and software combination suitable for operation as a server on the 
World Wide Web. an increasingly commercially-oriented segment of the publicly avatlable 
teteme. network. When the Windows operating system is used in .he applicauon bet. 
however, experience shows .ha. .he overall capacity of the OLTP system is substantially less 
for .he same hardware man .he capaci.y when .he UN!X operaring sys.em is used. Solv.ng 
«. capacty problem would encourage OLTP sys.ems ,o be implemented using Web server 

i u/ph servers as OLTP application servers 

technology on a private Intranet network, or using Web servers 

or data servers on the World Wide Web itself. 

Additional details on the background and the prob.cn, being solved by the present 
invention wiH be found in the article "Putting the Data Warehouse on the Intranet", appeanng 
in U^ntlSy^, May 1996, a periodical publtshed by Miller Freeman as a supplement to 
the periodical DBMS . 

SUMMARY OF THE INVENTION 
The presen, inven.ion provides an increase in capaci.y in a diem-server sys.em tha, 
uses a s,a,eless pro,„co, ,o access server da,a. The invenuon does .his by improving ne.worit 
_ica,io„ efficiency over .he ne,w„r k linking .he server S ys.em .o .he Cien.sys.em. For 
each initial clien. sysrem .ransacion reques, ,he server genera.es a unique idenufter, or 

hold the logica. connecrion .o .he server in an active or open condition u„.i, .he chen. 
sys.em is finished wi.h .he connec.ion and releases ... A. .he server, .he .o k en is use .o 

f ..ion iUo referred to as user context information, retained at the 
identify client state information., also reierrea 10 ^ 

,.,ith the client Follow-on communications 
server for use with follow-on communications with the client, r 
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from the client include the token, which the server uses to identify the stored client state 
information. 

The present invention further reduces network overhead by keeping alive the network 
connection between server system and client system, thereby reducing total system overhead. 
5 As a result, in one embodiment, the server creates only a single or a small number of 

operating system processes within the server system in response to a comparatively large 
number of client system transaction requests. Used individually or in combination, these 
improvements increase the capacity of a client-server system based upon a stateless 
communication protocol. 

10 In one preferred embodiment of the present invention, the data access system would 

include a client computer and a server. At least one database maintained on the server, the 
database having information to be distributed to the client computer and a token associated 
with the client, wherein the token represents the status of communications between the client 
computer and the server. The status of communications includes the identity of the client and 

15 the context of any communications between the client computer and the server. There would 
also be a communication path between the client computer and the server, each client 
computer programmed with a specialized computer software program providing an at least 
one data-entry field to allow a particular user of the client computer to complete a request of 
information to be retrieved from the server. There would also be a communication path 

20 between the server and the client, allowing the server to communicate a response to the 

particular user's request. In preferred embodiments, the communications between a client and 
a server may be encrypted, using a proprietary or public-key cryptosystem, allowing for 
secure communication over a communication link (e.g. network, satellite broadcasts, or cable 
TV) lacking in security. 



25 



BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 shows a block diagram of a prior art three-tier OLTP system based on the 
UNIX operating system. 
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FIG 2 shows a block diagram of an embodiment of a three-tier OLTP system 
according to the present invent.on usmg the Windows NT Server operat.ng system at the 

application server tier. 

FIG 3 shows a block diagram of an embodiment of a mree-tier OLTP system 
S fomented as a two-tier system wherein the database server software and the application 
server .software for a particular database are provided within a single computer sysrem usmg 
the Windows NT Server operating system. 

TO 4 shows diagrammatical* certain memory and software interaction between 
application system software and client system software to effect improvement* of the present 

W HO. 5 is a flowchart of the interaction between a chen, and a server communicating 

in accordance with an embodiment of .he present invention. 

FK) 6 is a more detailed view of .wo steps contained wtthtn .he FIG. 5 flowchart. 
FIO. 7 is a flowchart showing .he genera, handhng of cookies by a preferred 
l*> embodiment. 

DESCRIPTION OF SPECIFIC EMBODIMENTS 

. thrt* tier OLTP implementing an inventory control 

FIG 1 is an example prior art three-tier i r imp 0 

.stem. , FK, 1. da.abase server ,0 provides common access .o informarion records or 
user, connected ,o on line c.ien. system 30. Server .« inCudcs magnettc d.sk or other no - 

„f an inventory con.ro, sys.em. Server ,0 manages .be database usmg one of a number o 
commerce ava„ab,e database managemen. sys.ems. such as .he Oracle system so,d by 
Oracle Corporation of Redwood Shores, California. 

Database server 10 receives and responds to requests for database servtces over 
„ network .5 from one or more ap P ,ica.io„ servers 20 which imp.cmcn, a data-dependent 

of.warc application, such as an inventory control sy.s«em. Application server 20 recetves «, 
responds to requests for inventory control services over network 2S from one or more chen, 
Jems 30. One or more human users interact wi.b each c.ien. sys.em 30 usmg keyboard. 
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mouse, display monitor, printer or any number of other input/output devices to utilize the 
inventory control system. 

As shown in FIG. 1, prior art OLTP systems of this type generally utilize the UNIX 
operating system at each tier of the system. Database server 10 and application server 20 
typically communicate over network 15 utilizing calls for database services that are native to 
the particular database manager being utilized, Oracle in this specific embodiment, or else the 
ODBC Open Database Connectivity protocol which is an industry standard database 
communication protocol. All commercially important database management systems 
generally available, including Oracle, will accept standard ODBC requests and will provide 
standard ODBC responses over network 15. In this document ODBC is used illustratively 
throughout, but it will be understood to represent generally ODBC, the transaction language 
native to the specific database management system (DBMS), or any other transaction 
language suitable for database communications. 

Application server 20 and client system 30 using the UNIX operating system typically 
communicate over network 25 utilizing the Telnet UNIX industry standard communication 
protocol. The UNIX operating system at application server 20 can handle a significant 
number of simultaneous Telnet connections, so that total OLTP system capacity is sufficient 
for its intended purpose. 

FIG. 2 shows a block diagram of an embodiment of a three-tier OLTP system 
according to the present invention using the Windows NT Server operating system at the 
application server tier. Database server 40 and application server 50 communicate over 
network connection 45 using the ODBC or other protocol in a manner similar to the prior art 
system. Application server 50 is advantageously implemented using Web server technology 
under Windows NT Server. As part of this improvement, the HTTP Hypertext Transport 
Protocol is used on network 55 to communicate with client system 60. Client system 60 may 
use any operating system supporting the HTTP protocol, such as UNIX or one of the 
Windows products. 

In the embodiment of FIG. 2, the Web server features of the application server 50 are 
implemented in software using the Visual C++ Version 4.1 suite of development software 
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from Microsoft. Any programming language cou.d be used, but .his suite of software s 
particularly advantageous. This suite inCudes -ho Mrcrosoft Foundation Classes^ .he 
KAP. hnenre. Server Appiicarion Program .nterfaee .software. The 1SAPI prov.des 
rudimentary Web server and HTTP features .ha, ean be built upon using .he V.sual C~ 
compiler provided in rhe sui.e. SimHarly, in Cien, sy,em oO communiearion „,.h appl.cat.on 
S erver 50 over network eonnecUon 55 using .he HTTP promco, is impiemen.ed ustng the 
,SAPI expanded in an appropria.e fashion .0 oooperare wi.h .he software impiemen.ed a, 
server 50. .n .his way, appiiearion server 50 and e.ien. sysrem 60 cooperare ,o reduce ,he 
communication load over network connection 55. 

FIG 3 shows a block diagram of an embodiment of a three-.ier OLTP sys.em 
demented as a two-Uer system wherein .he database server software and the applicauon 
KI ver software for one par.icu.ar da.aba.se of the OLTP system are prov.de wuhtn a 
combinat.on server 7. using .he Windows NT Server operating system, .n the 
F1G 3 ODBC or other pro.oco. communication between the database management system 
a„a the app.ica.ion sy,em software is accomphshed wi, direc, software co—armn 
„ .he ,wo software sysrems rather .ban using a network connects The « NT 
Server operating system cooperates by supporting ODBC and other communtcaoon between 

separate systems. of lhe OL TP sysle m of F1C. 3 may be tmplcmented wttb 

Other particular databases of the OLI P system ui r 
separate servers for .he database softwat* and for the application software as prev.ous y 
JL in FIG. 2. Cent system 8 0 and ne.work connection ,5 operate in s.m.lar fashmn to 
the sysrem of FIG. 2. ftnprovements in OLTP system capacity of ,be present .nvenfto may be 
appfted to advantage in the case of a combinarion server arrangemcn, shown ,n FIG. 3. 

FIG 4 shows diagrammatically certain memory and software inrcracon between 
appHcatton system softwam and client system software .o effect improvements of .he present 
in Lon. When a new initial client server re q ues, is received by the apphcauon server 50 
th e application reserves an area in vola.ile memory for the opened communicatee a n*, 
ana Ites a token, a untrpte Cement of data, to identify the new user sesston and new 
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in volatile memory. Subsequent communications between client and application include the 
token to identify the communication session being utilized, and cause the user or client 
context information to be retained on the server as long as needed. So long as the context 
information is retained, the application server is able to make subsequent and repeated 
5 interchanges with the database server in response to client requests during the session. 

The client has responsibility for notifying the application when the session is ended 
and is to be dropped. In response to a drop notification, the application releases the memory 
that was reserved for the context information and the token is released. 

FIG. 4 also illustrates a portion of volatile memory used in the token and context 

10 arrangement just described. Application server 50 reserves a memory area 51 when a new 

initial client communication is received, and a token is created and stored away as a pointer to 
the client state information stored in memory area 51. Various items of client state, or 
context, information may be advantageously stored in memory area 51, depending on the 
needs of the specific application. In the present illustrative embodiment representing an 

15 inventory control system, an identifier of the current warehouse of interest to the user of the 
client system may be stored in memory area 51. The warehouse identifier information can 
then be included in ODBC or other protocol interactions with the DBMS. The current 
warehouse identifier may be changed from timc-to-time as the user's utilization of the 
inventory system continues over subsequent inquiries during the same session, and the token 

20 returned from the client with the subsequent inquiries provides an effective means for 
locating and updating the user context information. 

The token is transmitted over network connection 55 to client system 60 where it is 
retained in memory area 61, which may be volatile or non- volatile, depending on the 
embodiment, until no longer needed. In some embodiments, the token may be retained in 

25 volatile memory only until the next transmission of data back to the application server 

wherein the token is included in the return data. In other embodiments, the token may be 
retained at the client system for a longer period of time, depending on the advantageous use 
that can be made of the token by the client system, as, for example, until the end of the 
session. The token may be retained at the client system at least until the text transmission of 
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dam back ,0 .he apportion server, and fo, a longer period, for example, in embod,men, S 
wherein client sys.cm 60 supports a plurali.y of human users, and user comcx, informal 
useful .0 .he alien, is maintained in .he clien. sys,em. or embodime„,s wherein ,he .oxen 
serves differen, or addi.ional fune.ions, sueh as a role in securiry features or o,her funcons 
rc.ated ,o database functions, application functions, clien. functions or commumcauon 

functions. . 

,„ any even,, client system 60 transmits .he .olcen ,o application system 50 . one or 
more subsequent communications .o identify .he session and the memory area 5. allocated to 
tte clien, state information. While .he session with me client is open, applicanon server 50 .s 
able to make any number of database interchanges with the database server over the ODBC 
communication channel, either a channel provided by network as illustrated in FIG. 2. or a 

channel provided by software as illustrated in FIG. 3. 

. „ H.»n .rcess svstem capacity can be obtained by using the 
Additional improvements in data access sysiem w P y 

token and client context arrangement described above ,n combination with a mechanism tor 

naming a con.tnuous network eonnecion between the client sys.em and server sysumv 

A „ advan.a B =o„s means for accomplishing .his resul, is provided by the keep.ahve feature 

provided by ceriain implementations of the HTTP protocol. Such an imp,emen,a„„n , found 

in the HTTP protocol provided by the Web .server software available from Microsoft for use 

with Windows NT Serve, and by the M.crosoft interne, Explore, Web browser software tha, 

operates in conjunction with Windows NT. Using this browser or equivalent software ,n he 

cln, system of FIG. 2 or FK3. 3 makes the keep.alive featum available. When a keep.ahv 

.quest is issued by one system .o ,he other over me network connection, the reoptea .. of .he 

req „est maintains the communication channel unt„ it is released by me requester. U> thts way 

system overhead is further reduced and system capacity is further increased for mult.ple 

interactions or transactions within a session. In the present invention, the HTTP 

communication channel between the client and app.icarion servers can be made contmuous as 

long as reasonably needed. 

,» the pr,or an. U is known for an appHcation server to initiate a keep.ahve request to 
,„e client system when the application server has a need to transmi. rela.ively large amounrs 
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of data requested by the client, such as graphics data, usually in repeated transmissions. By 
making a keep_alive request to the client, the application prevents the communication 
channel from being dropped until the application has finished transmitting all the data 
requested during subsequent transmissions by the application. 
5 In the present invention, the client makes a keep__alivc request to the application in 

anticipation of a number of repeated interchanges of information with the application. Having 
received a keep_ali ve request from the client, the Web server, if designed to operate with the 
keep_alive option, can choose to honor the keep_alive request or not. In the embodiments of 
the present invention wherein keep_alive is used in conjunction with the token and client 
10 context arrangement previously described, the Web server, in conjunction with the 

application software, honors the keep_alive request and returns a notification to that effect to 
the client. Thereafter, communications over the HTTP network connection is more efficient 
since the connection is not taken down after each message and re-established anew with the 
following message. This is a particularly advantageous arrangement that enhances the 

15 efficiency of the token and client context arrangement previously described. 

FIGS. 5 and 6 show, in flow-chart form, an over- view of the interaction between a 
client system and the server system in an illustrative application server computer program for 
a simplified example inventory control system having features in accordance with the present 
invention that has been described hereinabove. In FIG. 5, step 100, a client initially types in 

20 the Universal Resource Locator (URL) address of the server system to contact. The server, at 
step 102, verifies whether or not the server already has context data for the contacting Client. 
If there is no context data for the client, at step 104, the server returns a login form to the 
client, which requests that the client submit identification information. At step 106, the client 
submits the filled in login form, and the server, at step 108, creates user context information 

25 and the cookie associated with that context information. Then, at step 110, the server sends 
the client a menu of actions/functions the client can request the server perform, where 
embedded within the form is the cookie associated with the client's context information. At 
step 112, the client selects an action from the menu, and this selection is transmitted to the 
server. Embedded within this and other communications with the server is the cookie value 
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ge„era.ed in step 108. ,f .he client has not chosen to qu„ .he program a. step .14. rcsu...ng ,n 
!„ end ro the connection wirh the server a. step 1.6. .he program flow ,„op S back .o s.ep .02 
in which .he server verifies .here is a eon.ex, for .he ciien. <wh.ch has jus. been created a. 
„ep ,08), and ,hen a, step 1,8 .he server eva,ua.e S .he se.ee.ed acion/funcfion chosen ■„ s.ep 
UZ If .he reques. is no. vafid, either dne to the curren. contex. for the nser, garbled 

„. .„.„ i M the server sends the client an error message, 
transmission, or some other error, at step 122. the server 

M step 124. of FIGS. 5 and 6, .he server performs .he chosen ac.ion/funcuon. FIG. 6 
shows a, steps ,50-162, for one preferred embodiment of the present inven.ion. the available 
acions/funcions .he client may request. ,n a preferred embodiment, a, step .50 .he server 
evn.ua.es wbemer the CieMchose to print new order results, step ,52. prin. delivery resuhs a, 
s,ep .54, prin, paymen, results a, s.ep ISC prin. stock -Is a. s.ep .58. prin, order s,a.us 
informafion a, s.ep ,60. o, process a login form a, s.ep ,62. In preferred embodiments, .he 
clien, login form is treated as any other request .he client may make. 

A, step ,26. of FIGS. 5 and 6. rhe server .ransmi.s to the cl.en. .be results of 
performing ,he reques.ed function. FIG. 5 indiea.es tha, afler returning results in step ,26. 
program con.ro, loops back to step 1,0 in which the user is .hen presented w„h me menu of 
actions/functions that may be performed. 

Described hereinbelow is a more de.ai.ed-v,ew of .he iflustrarivc inven.ory control 
prog ram uri.ired in FIG. 5 and FIG. 6. The i.lu,ra.ive program was compiled w.th .he 
Milof, Visua, C~ Compiler Vers.on 4, to form an embodiment of the present _. 
b. another compiler and o, language may have been used instead. A,so no,c that the 

• . An a m ho i fullv functional nor fully operational inventory 
following description is not intended to be a hilly mncuo 

COmr0 ' CI the .nventory con.ro, app.ication provides HTML Hypertcx, Markup 
Language forms to .he elien. system .hrough Web server software. The user of .be c.mn. 
sys,em, using an available Web browser such as .he Microsoft In.erne. Explorer Web 
User. Js informarion in.o the forms and selects screen bu.mns appearing on the forms. 
Th e Web bLc, a, the Cien. system re.urns each fi„ed-in lorm to the applicaoon s»«em 
which pa.es the form (Fig. 5 s.ep 1.8) and selects .he informarion of in.eres, (s,ep 124,. 
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response to a login form (step 106) identifying a new user session, the application will reserve 
an area of user context memory and assign a token (step 108), referred to as the "cookie" in 
the computer program code described hereinbelow. The cookie is inserted into each of the 
forms that will thereafter be sent to the user of the client system. When the received form is 
5 filled in by the user and returned to the application for processing, the cookie that was placed 
in the form by the application identifies the user session for the application. The application 
uses the cookie to locate the user context information to aid further processing of the 
information provided on the form, or for communicating with the database server, or both. 
When the user presses the "Exit" screen button on the form presented by the client system 

10 (step 114), the form data is returned to the application which determines that the Exit button 
was pressed. The application then releases the user context memory and releases the cookie 
(token) for re-use by another user, ending the current user session (step 116). 

In a preferred embodiment of the inventory control program, basic utility functions are 
needed to interface a Web browser with a database storage system. Common to most support 

15 functions, is that each contains a reference to a cookie (token), and this cookie is used to load 
a context for a particular user. The context is a memory area reserved for the cookie in each 
form that will be returned to the user. For any given transaction by a client being processed by 
a server, a preferred embodiment will utilize data structures containing fields for tracking data 
relevant to the transaction taking place between the client and server. For example, once such 

20 structure, referenced herein as the raw data form structure, contains entries for identifying the 
form in use by the client, entries for a product, service or resource being reviewed by the 
client, quantity indicators, and other data concerning a transaction taking place with a client. 
Such data structures are then used by the support functions to enter and manipulate 
transaction data. 

25 One such support function is PrintStaticPagc(), which is used to send responses back 

to a client's browser. As described hereinabove, generally a client user will connect to a 
server computer through a Web browser, and be presented with a form allowing the user to 
indicate an action to be performed by the server, such as to perform a price check. In response 
to this request, different components to the invention perform the database retrieval operation, 
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«, the PrintStaticPageO is ten called .o dynatmcally create a formatted HTML page 
containing ,he results of Che request. This formaued HTML page is .hen sen! back ,o .he 
clien. browser so .hat the results of the request may be seen. 

Another support function is VerifyNewOrderLineO. which verifies tha. a user's tnpu. 
,o a form is valid, and returns an error indicating .he location of any errors (such as 
unexpected blank responses,. This function is representative of a set of functions which each 
verify a certain .ype of input field. Verifying VcrifyShortO. etc. are also ,n ,h.s set. 
VerifyNewOrderLine is more complex in tha. i. checks an entire order fine (composed of 
triple fields, (or vaUdiry. 1. is called during a New Order transaction, and wou,d also be 
called from PrintNewOrderResultsO (which is a,so a function representee of a sc, 
of functions, one for each specific transaction), and which interprets a user's response to mpu, 
forms and generates .he appropriate response page data (which is .hen gtven to 
Prin,S,a.icPage ( , for transmit.* to the client browser). This function is passed a pointer to te 
user's que* data, and a pointer to a raw form data structure contatmng all poss,b,c field .ha. 
m ay be assigned va,ues during interacting with a particular client. Initially 0,1s funerton (as do 
«l functions in a preferted embodiment, uses the user's assigned cookie to remove the 

processing, al, entries upon the form are passed ,o this function as a long character stnng. and 
L s.r,ng is parsed and stored into the raw data fortn structure. After pars.ng .he Cent s 
conrex. information on the server is updated ,o refiec, the new Cent data, and subsequent 
references to the user's cookie will include the newly tracked data. 

1„ a preferred embodiment, for communicating with a database, entries from the raw 
form are copied into a predefined dambascaccess field. This access field, as well as o.hcr 
dal abasc related strucures and operations used by a preferred embodiment .o mterac, w, h a 
SQL-type database, have been defined in the Mterosof. TPC-C Benchmark Kit, verston .04 
.-eretnaf.er Benchmark Kit, Once appropriate values have been copied into the access * 
lte field is .hen passed to the SQLNewOrderO function (defined by .he Benchmark Ktt) ro 
effect a database query. 
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Other support functions, such as PrintPaymentResults(), PrintOrderStatusResultsQ, 
PrintDeliveryResultsO, PrintStockLevelResultsQ, are also passed as arguments to the 
function, a pointer to the user's query data, and a pointer to the raw form data for storing the 
parsed query data. This parsed data is then used to fill in data structures relevant to the 

5 particular action to be performed. Thus, for example, a predefined structure of type 

PAYMENT_DATA is filled with data concerning exactly when in time the transaction took 
place, the nature and status of the transaction, etc. This retrieval is accomplished by passing 
the predefined structure to a SQLOrderStatus() function (defined by the Benchmark Kit), 
which queries the appropriate SQL database and fills in the predefined structure. 

10 In addition to the support functions, in a preferred embodiment of the inventory 

control program, are handling functions which interpret user responses to the forms and 
provide some of the basic functions found in an inventory control system. In each user 
response form, the cookie is retrieved from the form, converted from a string into a number, 
and the number used to index into an array (m_pContcxt) of user context information from an 

1 5 operating server. 

One such handling function is ProccssLoginForm(); this function generates a request 
for the allocation of a new user context memory area and the creation of an associated cookie 
that refers to it. Another handling function, ParseFormData(), breaks up the data string 
comprising the form sent from the client system into individual data units, the cookie being 

20 one such data unit. Another handling function, SelcctPage(), takes the cookie returned from 

the client system in string form, converts it into a number that can be used as an index into the 
user context array, and checks its validity. Then the function branches into one of a number of 
paths that process a specific request made by the user (step 124), and determines which output 
page should be displayed back to the user. In a preferred embodiment of the inventory control 

25 program example, each of the forms labeled nform and oform are created at the outset during 
login, and initialized with the cookie for future use. Input received from a user are tagged, 
such that if the user pressed the exit button, the server program would receive an action case 
of 'E\ causing a function call to release the user context memory area and the cookie. Other 
actions are similarly tagged for processing by the server. 



3NSDOCID: <WO 9740457A2_I_> 



PCT/US97/06468 

WO 97/40457 

- 16- 



10 



15 



20 



25 



Another handling function is HttpExtensionProcQ; this function, in response to a 
keep alive request from the client, this function complies with the request and returns a value 
to the client that keeps the network connection active. In a preferred embodm-ent, each chent 
communication from the Web browser to the Web server includes a request to keep the 
connection alive. The Web server complies and returns a similar request to the client. In ttus 
way the network connection is retained so long as needed. This in contrast to the normal 
browser connection mode in which all actions are atomic, and a new network connecuon 
m ade to the server each time the client attempts to take any action. For commumcauons 
transmitted with keep.alive in this specific embodiment, an additiona. data item specifymg 
the length of the transmitted message is appended when a message is sent across the network 
connection. In this way, the receiver can determine when the transmitted message has been 
completely received. After the application software processes an Exit button press, as 
previously described hereinabove, the response message to the client does not return a 
keep.alive request, permitting the connection to be dropped. 

" Another handling function is CreateContexU); this function (step 108) reserves a 
cookie for the user session by finding a free slot in an array of pointers to context memory 
entries, and the user context memory area associated with the cookie. The contexts are stored 
upon the server, and each user context contains working copies of the response forms wtth the 
cookie entered into them. When a context is created, a connection is made to the database and 
information regarding this connection is stored within the context. In the inventory control 
program, this context also contains information such as warehouse and district identtfiers 
provided by the user. 

M ,o CreateCon.ex.0 is the FreeConrex.0 function that dek.es .he user come*, 
and marks the array s.o, free for future use. In a preferred embodimenr, .his function reeeWes 
as an argument a cookie, and if a user session is associated w,.h .he cookie, .he associated 
database connection is closed, and associated resources released. 

RG 7 is a flowchart showing the general handling of cookies by a preferred 
embodiment. InLial.y. the program waits 200 fo, a user request to be rece.ved; during the fir* 
request, a connection is automatically e S .ablished wi.h a server. A check is made 202 ,o 
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determine whether a token was embedded in the request, and if not, an initial context is 
created 204 on the server. After the context has been created, the users 1 request is then 
processed 206 according to the request type and associated data. During processing, the 
client's sate information is updated according to the transaction processed. After processing, a 
test is made 208 to determine if the action taken by the user was to perform a logoff from the 
server. If so, then the context for the user is deleted 210 and a logoff response (without a 
cookie/token) is presented to the user and the user drops the connection. If it was not a logoff 
request, then the user is sent a response 210 (containing a cookie) corresponding to the results 
of the requested transaction. The connection is not dropped by the user, and the server 
continues to wait 200 for further requests from the user. 

In addition to the embodiments disclosed above, additional embodiments of the 
invention will be apparent to those with ordinary skill in the art without departing from the 
teachings of the invention. For example, instead of basing the communications between the 
client system and the server system solely upon HTML or HTTP. Java (a 
platform-independent multi-threaded, dynamic general -purpose programming environment 
for creating applets and applications for distributed networks by Sun Microsystems Inc.) or its 
equivalent may be used to augment the functionality of the system. And, although the claims 
are written towards the base case of one client system talking to a single server which has one 
database maintained on the server, there could be many servers, located centrally or spread 
out over a network such as the Internet, each server having one or more databases containing 
data for retrieval by client systems. 
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What is claimed is: 

1 A data access system comprising: 
a client computer; 
a servers 

a database maintained on the server, the database having 
i) information to be dis.ribn.ed <o .he elienl eompmer, and 
m a .okcn associated with the elient, wherein the token represents the 

status of communica.ions berween the c.ien. eompmer and .he server; 
a con.mnniea.ion pa.h be.ween .he elien, compnter and the serve, eaeh ehen. 
eompmer programmed with a specialized eompmer software program provid.ng an a, 
,cas, one da.a-emry field to allow a particular nser of the c.ien. eompmer ,o eomplcre 
a reqnes. of information .o be relieved from .he server; and 

a communication parh be,ween .he server and the cfien,. aUowing .he server ,o 
communicate a response to .he particular user's reques,. 
, A svs,em as described in claim 1 , wherein .he suuus of commumcauons between he 
" cjn, computer and the server includes .he identiry of .he e.ien. and the context of an y 

commun.cationsbc.ween .he client computer and .he server. 
y a system as described in claim 1. wherein the communication P a.hs be.ween the 
client and the server are stateless. 

4 A system according ,o Cairn 1 , wherein .he communication paths be.ween the Cent 
and the server are based upon using a Telne, communicarion protocol. 

5 A system as described in claim 1. wherein me communicarion P a.hs boween .he 
" cent and .he server are based upon using word wide web access software. 

„ A sysrem as described in claim 5, wherein communing with .he da.abase further 

"""a processor for -changing an a, leas, one p.ain-tex, message so as ,„ establish 
a secure communicarion path through use o, a public-key cryp.osys.em. and 

an encryption processor for exchanging encrypted information between the 
server and the client eompmer after establishing .he secure communicarion pa.h. 



20 



NSDOC1D <WO _8740457A2J_» 



WO 97/40457 



- 19- 



PCT/US97/06468 



7. A system as described in claim 1, wherein the communication paths between the 
client and the server are based upon using software which implements the Hypertext 
Markup Language specification. 

8. A system as described in claim 1, wherein the communication paths between the 
client and the server are based upon using software which implements a 
platform-independent multi-threaded, dynamic general-purpose programming 
environment for dynamically creating applets and applications for accessing the 
database over a distributed network. 

9. A system as described in claim 8, wherein the general -purpose programming 
environment is object-oriented. 

10. A data access system comprising: 

a client system and a server system in communication over a network, the 
client system providing requests over the network to the server system, and the server 
system providing data to the client system in response to the requests; 

a first memory area, within the server system, for storing client context data 
regarding data requests from the client system; 

a token, generated by the server, which identifies the first memory area, and 
which is returned to the client system; 

a second memory area, within the client system, which stores the token 
received from the server system; and 

an at least one request by the client which includes the token generated by the 

server. 

i 1 . A data access system according to claim 10, further comprising: 

the at least one request including a keep_alive indicator value along with the 
request to the server system, so that the server system maintains an open network 
connection to the client system until the client system sends a countermanding request 
to the server system to drop the network connection. 
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12 An on-line transaction processing system comprising: 

a database server, an application server, and a client system; 

• , ™ ™t h between the database server and the application 
a first communication path between u.c 

. . „„ th h _ in „ OV er a first network connection using a first 
server, the first communication path being over a 

communication protocol; 

„,v, v^tvjrm the application server and the client 
a second communication path between tne appu^ 

• .• „,ti, Vv»inP over a second network connection using 
server, the second communication path being over a sec 

a second communication protocol; 

a keep alive reques. .ransmiued by the chen, server to rhe app.ica.ion server 
„ accordance wi,h .he second con—don prorocC. in response ,o which .he 
apphca.ion server reserves an area of vohude memory in response ro sard keep,ah 
Z*». a unique ,oke» idendfying rhe area of vohude memory, and «— 

1 unique ,oken .o said clien, server in accordance wirh sa,d second commun,ca,,o„ 
protocol; and 

wherein .he dien, server re.ains ,he unique ,okcn. and ,ransm„s rhe un.que 
mken ,o rhe apphcadon server in accordance with .he second pro.oeo, in como.nanon 
with requests for database services. 
, 3 A memod for performing an on-line .ransacdon processing sys.cm compnsmg. 

providing a e.ien, and a server communing over a nc,work us.ng a f,rs. 

20 ncwork communicalion protocol; 

sending a Universal Resource U*a,or reques. to a server, 
verifying .ha, a comex. exists at .he server for .he clien, and requesung 
information reganimg d,e clicn. if no such con.ex, exists. 

creaung a token represen.ing me curren. s,atc of communicauon w„h .he 
25 e.ien,. wherein such token is nansmit.ed ,o and gained hy .he chen,. 

dismaying a menu of information or serv.ces ,he ehen, may reques, of .he 

server* 

' ' selecting the information or service from the menu and transmitting a request, 
along with the token, to the server; 
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parsing the request received from the client; and if a valid request, acting upon 
the request; and 

communicating the result to the client. 
14. A method as described in claim 12, wherein the first network communication protocol 
5 is a stateless protocol, and wherein use of the token results in a second network 

communication protocol containing state information. 

41.W4 
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information. The application server (50) may be implemented 
using Web server technology. If the HTTP Hypertext Transport 
Protocol is used on a network (55) to communicate with the 
client (60), then the Client (60) may use any operating system 
supporting the HTTP protocol. 
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AL Albania 

AM Armenia 

AT Austria 

AU Australia 

AZ Azerbaijan 

BA Bosnia and Herzegovina 

BB Barbados 

BE Belgium 

BF Burkina Faso 

BG Bulgaria 

BJ Benin 

BR Brazil 

BY ' Belarus 

CA Canada 

CF Central African Republic 

CG Congo 

CH Switzerland 

CI Cote d'lvoire 

CM Cameroon 

CN China 

CU Cuba 

CZ Czech Republic 

DE Germany 

DK Denmark 

EE Estonia 
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FI 

FR 

GA 

GB 

GE 

GH 

GN 

GR 

HU 

IE 
Il- 
IS 
IT 
JP 
KE 
KG 
KP 

KR 

KZ 

LC 

U 

LK 

LR 



Finland 
Prance 
Gabon 

Unhed Kingdom 

Georgia 

Ghana 

Guinea 

Greece 

Hungary 

Ireland 

Israel 

Iceland 

Italy 

Japan 

Kenya 

Kyrgyzstan 

Democratic People's 

Republic of Korea 

Republic of Korea 

Kazakstan 
Saint Lucia 
Liechtenstein 
Sri Lanka 
Liberia 
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LT 

LU 

LV 

MC 

MD 

MG 

MK 



Lesotho 



Luxembourg 

Latvia 

Monaco 

Republic of Moldova 

Madagascar 

The former Yugoslav 

Republic of Macedonia 



ML 


Malt 


MN 


Mongolia 


MR 


Mauritania 


MW 


Malawi 


MX 


Mexico 


NE 


Niger 


NL 


Netherlands 


NO 


Norway 


NZ 


New Zealand 


PL 


Poland 


PT 


Portugal 


RO 


Romania 


RU 


Russian Federation 


SD 


Sudan 


SE 


Sweden 


SG 


Singapore 



SI 


Slovenia 


SK 


Slovakia 


SN 


Senegal 


sz 


Swaziland 


TO 


Chad 


TG 


Togo 


TJ 


Tajikistan 


TM 


Turkmenistan 


TR 


Turkey 


TT 


Trinidad and Tobago 


UA 


Ukraine 


UG 


Uganda 


US 


United Slates of America 


uz 


Uzbekistan 


VN 


Viet Nam 


YU 


Yugoslavia 


zw 


Zimbabwe 
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